Method and system for adaptive delivery of digital messages

ABSTRACT

A system and method for automatically adapting digital message traffic flow evaluates message delivery disposition, latency and performance metrics such that the system operates more optimally in terms of both overall throughput as well as with respect to system sending reputation. Reputation is in the context of maintaining message flow within limits that are acceptable for a given destination, such that the sender behavior avoids being flagged as abusive or otherwise undesirable.

CROSS-REFERENCE TO RELATED APPLICATION

This is a continuation-in-part application that claims priority to theU.S. regular patent application Ser. No. 13/079,449, which was filed onApr. 4, 2011, and to the U.S. provisional patent application No.61/320,619 that was filed Apr. 2, 2010, both of which were filed by thepresent inventors. The entire disclosures of these priority documentsare incorporated herein by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to methods and systems for controllingdelivery of digital messages such as E-mails transmitted via networks ofcomputer systems.

2. Description of the Related Art

Transmission of information in the form of digital messages overcomputer communication networks such as e-mail and text messages is anessential component of modern lives, in both business and leisure. Manybusinesses derive income from services built “on top of” digitalmessaging. For example, almost all online purchases trigger a message toconfirm that a monetary transaction has taken place. Schools areincreasingly making use of alerting services that broadcast textmessages to mobile devices. Businesses use E-mail and instant messagingas an essential part of day-to-day business communication, bothinternally and externally. Internet Service Providers (“ISPs”) enableemail services for personal and business use. E-mail Service Providers(“ESPs”) enable other businesses to efficiently send their marketing andother types of communication without requiring a significant investmentin sending infrastructure. “Aggregators” provide gateways to textmessaging protocols and act as an endpoint for submitting Short MessageService (“SMS”) and Multimedia Message Service (“MMS”) messages to cellphone provider networks.

Many digital messaging systems that send digital messages over theInternet use protocols such as Simple Mail Transfer Protocol (“SMTP”),in the case of E-mail, and other protocols when the digital message isother than e-mail, to send digital messages from one server to another.The messages can then be retrieved with a client using services such asPost Office Protocol (“POP”) or Internet Message Access Protocol(“IMAP”). Other protocols for sending digital messages that are e-mailsinclude, but are not limited to, POP3, X.400 InternationalTelecommunication Union standard (X.400), and the Novell messagehandling service (“MHS”) as well as the Extended Simple Mail TransferProtocol (“ESMTP”). Examples of prior art message delivery systems areillustrated in FIGS. 1A, 1B, 1C and 2.

SMTP transports digital messages among different hosts within theTransmission Control Protocol/Internet Protocol (“TCP/IP”). Under SMTP,a client SMTP process opens a TCP connection to a server SMTP process ona remote host and attempts to send mail across the connection. Theserver SMTP process listens for a TCP connection on a selected port andthe client SMTP process initiates a connection on the selected port.When the TCP connection is successful, the two processes execute asimple request-response dialogue, defined by the SMTP protocol, duringwhich the client process transmits the mail addresses of the originatorand the recipient(s) for a message. When the server process acceptsthese mail addresses, the client process transmits the e-mail instantmessage. The e-mail message contains a message header and message text(“body”) formatted in accordance with RFC 822 STD 11, the Standard forthe format of Internet Text Messages. Mail that arrives via SMTP isforwarded to a remote server or it is delivered to mailboxes on thelocal server. Similar protocols are used for other digital messageformats (i.e., other than e-mail).

The SMTP protocol (see, e.g., RFC 821 or the recently updated standardRFC5321) supports both end-to-end (no intermediate message transferagents “MTAs”) and store-and-forward mail delivery methods. Theend-to-end method is used between organizations, and thestore-and-forward method is chosen for operating within organizationsthat have TCP/IP and SMTP-based networks. A SMTP client will contact thedestination host's SMTP server directly to deliver the mail. It willkeep the mail item from being transmitted until it has been successfullycopied to the recipient's SMTP.

This is different from the store-and-forward principle that is common inmany other electronic mailing systems, where the mail item may passthrough a number of intermediate hosts in the same network on its way tothe destination and where successful transmission from the sender onlyindicates that the mail item has reached the first intermediate hop. TheRFC 821 standard defines a client-server protocol. The client SMTP isthe one which initiates the session (that is, the sending SMTP) and theserver is the one that responds (the receiving SMTP) to the sessionrequest. Because the client SMTP frequently acts as a server for auser-mailing program, however, it is often simpler to refer to theclient as the sender-SMTP and to the server as the receiver-SMTP. AnSMTP-based process can transfer electronic mail to another process onthe same network or to another network via a relay or gateway processaccessible to both networks. An e-mail message may pass through a numberof intermediate relay or gateway hosts on its path from a sender to arecipient.

An example of the components of an SMTP system is illustrated in FIG.1A. Systems that send digital messages other than e-mail have similarcomponents. Referring to FIG. 1A, users deal with a user agent (“UA”,e.g., 120 and 160). The user agents for Windows™ include MicrosoftOutlook™. The exchange of e-mail using, for example, TCP, is performedby a Message Transfer Agent (“MTA” e.g., 140 or 150). The user's localMTA maintains a mail queue so that it can schedule repeat deliveryattempts in case a remote server is unable. Also the local MTA deliversmail to mailboxes, and the information can be downloaded by the UA (seeFIG. 1A). The SMTP protocol defines a mechanism of communication betweentwo MTAs across a single TCP connection. As a result of a user mailrequest, the sender-SMTP establishes a two-way connection with areceiver-SMTP. The receiver-SMTP can be either the ultimate destinationor an intermediate one (known as a mail gateway). The sender-SMTP willgenerate commands, which are replied to by the receiver-SMTP (see FIG.1C).

A typical e-mail delivery process is as follows. Delivery processes fordigital messages other than e-mail follow similar scenarios. In thefollowing scenario, a sending user at terminal 100 sends an e-mailmessage to a recipient user at an e-mail address: recipient@example.org.Recipient can review that e-mail message at terminal 170. Recipient'sISP uses mail transfer agent MTA 150.

Initially, the sending user composes the message and actuates or chooses“send” using mail user agent (MUA) 120. The sending user's e-mailmessage identifies one or more intended recipients (e.g., destinatione-mail addresses), a subject heading, and a message body, and mayspecify one or more attachments.

Next, MUA 120 queries a DNS server (not shown) for the IP address of thelocal mail server running MTA 140. The DNS server translates the domainname into an IP address of the local mail server and User agent 120opens an SMTP connection to the local mail server running MTA 140. Themessage is transmitted to the local mail server using the SMTP protocol.An MTA (also called a mail server, or a mail exchange server in thecontext of the Domain Name System) is a computer program or softwareagent that transfers electronic mail messages from one computer toanother. The message is transmitted to MTA 150 from MTA 140 using theSMTP protocol over a TCP connection.

The recipient user at terminal 170 has user agent 160 downloadrecipient's new messages, including the sending user's e-mail message.The recipient's MTA 150 is responsible for queuing up messages andarranging for their distribution. MTA 150 “listens” for incoming e-mailmessages on the SMTP port, and when an e-mail message is detected, ithandles the message according to configuration settings or policieschosen by the system administrator. Those policies can be defined inaccordance with relevant standards such as Request for Comment documents(RFCs). Typically, the mail server or MTA must temporarily storeincoming and outgoing messages in a queue, known as a the “mail queue.”Actual size of the mail queue is highly dependent on one's systemresources and daily message volumes.

In some instances, referring to FIG. 1B, communication between a sendinghost (client) and a receiving host (server), could involve a processknown as “relaying”. In addition to one MTA at the sender site and oneat the receiving site, other MTAs, acting as client or server, can relaythe electronic mail across the network. This scenario of communicationbetween the sender and the receiver can be accomplished through the useof a digital message gateway, which is a relay MTA that can receivedigital messages prepared by a protocol other than SMTP and transform itto the SMTP format before sending it. The digital message gateway canalso receive digital messages in the SMTP format, change it to anotherformat, and then send it to the MTA of the client that does not use theTCP/IP protocol suite. In various implementations, there is thecapability to exchange mail between the TCP/IP SMTP mailing system andthe locally used mailing systems. These applications are called digitalmessage gateways or mail bridges. Sending digital messages (e.g.,e-mail) through a digital message gateway may alter the end-to-enddelivery specification, because SMTP will only guarantee delivery to themail-gateway host, not to the real destination host, which is locatedbeyond the TCP/IP network. When a digital message gateway is used, theSMTP end-to-end transmission is host-to-gateway, gateway-to-host orgateway-to-gateway; the behavior beyond the gateway is not defined bySMTP.

Existing digital message sending systems are sometimes unsatisfactory.Digital messages (e.g., e-mail) sent to a given domain (e.g., aparticular ISP) or site may be blocked. However, typically, the blockingdomain will either not specify why the digital message was blocked orwill provide incomplete information as to why the message was blocked.In one example, the reason why a domain will block incoming digitalmessages is that a digital message quota, where the quota is based forexample on a number of allowed digital messages per unit of time (e.g.,per day, per week, per month) from the sending domain has been exceeded.However, the conventional sending digital messaging sending system(e.g., MTA 140 of FIG. 1A) does not learn that a quota has been exceededfrom the message failure notices that are returned to the sending MTA bythe blocking domain. So the digital message sending system continues toresend the blocked digital messages and send any new additional digitalmessages (e.g., e-mail, text messages, etc.) in its queue to theblocking domain even though there is no chance that the blocking domainwill accept the resent digital messages or the new digital messages fromthe digital message sending system because the quota has been exceeded.

In another example, the receiving domain may be down because ofequipment failure or scheduled maintenance. There are, therefore, manyreasons why a digital message sending system may send digital messagesto the receiving domain and meet with failure. But the digital messagesending system will continue to resend the digital message and any newdigital message in its queue to the receiving domain on somepredetermined retry basis without intelligently backing off from itsefforts to send out the digital message to the domain that is down.

It is reported that the majority of E-mail traffic (in excess of 80-90%,depending on the source of the statistics) is classified as “Spam”(unsolicited or otherwise unwanted messages). It is increasinglydifficult for both senders and receivers to ensure that E-mail messagesarrive successfully at the intended recipient's inbox. This is due inpart to a pessimistic stance being adopted by the receivers; theirinbound systems are burdened with the task of accurately classifying andprocessing messages that may have Spam, Virus or Phishing content andE-mail receivers are fighting a constant battle with the increasingvolume of unwanted messages and trying to balance that with anincreasing cost in infrastructure to deal with that load. This hasresulted in systems programmed to implement a set of incoming E-mailprocessing policies that penalize bulk senders by throttling backreception rates or delaying inbound mail reception, making it difficultfor their E-mail to reach the inbox on-time if ever. These receiverpolicies result in “Deliverability Issues” for the senders; not only isdelivery slowed down, but it is often done in such a way that makes itdifficult for the sending system to take appropriate action.

Many smaller E-mail sending sites resort to tricks at the firewall thatresult in traffic mysteriously stopping, rather than sending back adefinitive response code. This tactic is aimed at illegitimate senderswhere it is effective at avoiding load, but is especially harmful tolegitimate senders because it increases the resource utilization of thesending system by making the sending system try harder to deliver themessages. The slowdown in reception causes a bottleneck on the sendingsystem that increases resource utilization and CPU load, and can in turnhave an impact on the sending rates for mail intended for otherdestinations.

If a sender is seen to trigger enough of these receiver policies, thesender may have their sending IP address placed on a “blacklist” sharedwith other recipient domains. Blacklisting causes the triggering senderto have deliverability issues at other receiving sites too. The resultof these conditions is that it is difficult for a legitimate bulk senderto achieve high throughput without establishing some kind ofrelationship, either directly or indirectly through a “deliverabilityexpert”, with the administrators for the domains to which they intend todeliver their mail. Such a relationship will enable the sender todetermine traffic shaping parameters or rules that are acceptable to therecipient and are typically dependent on the volume of messages beingsent over an extended period of time and the historical and ongoingreputation of the sender (e.g., is this sender a known spammer, or doesthis sender otherwise have a high complaint rate from the ultimaterecipients?). Other factors may apply; the inbound mail policies are notnecessarily public and, by necessity, the policies change over time.

Having established appropriate traffic shaping parameters or rules for agiven recipient domain, the sender's software can be configured torespect those rules. As the rules change, the software configurationwill also need to be adjusted accordingly. This is an ongoing supportburden for both the sender and the receiver of messages. Even with thecorrect shaping rules in place, it is possible for a sender to trip upand damage their reputation.

Many senders re-sell their services to others and act as Email ServiceProviders (ESPs). It is possible for an ESP customer to send a batch ofe-mail that is widely regarded as spam; if enough of this content issent through the ESP system it can result in blacklisting the system andimpact the mail throughput for other customers of that ESP. A diligentadministrator at an ESP should be able to monitor and take action in theaforementioned case, but would need to be very focused on that task tobe effective.

While much of this document refers to E-mail, the same principles andproblems apply to all digital messaging protocols and platforms; textmessaging (SMS), multimedia messaging (MMS), instant messaging (XMPP andother proprietary protocols). Popular social media platforms, such asTwitter.sup^(SM) and Facebook.sup^(SM) also expose messaging interfacesfor external applications to similar problems.

There is a need, therefore, for a convenient, flexible and effectivemethod and system for adapting to changes and controlling delivery ofdigital messages such as E-mails transmitted via networks of computersystems.

BRIEF SUMMARY OF THE INVENTION

Accordingly, it is an object of the present invention to overcome theabove mentioned difficulties by providing a convenient, flexible andeffective method and system for adapting to changes and controllingdelivery of digital messages such as E-mails transmitted via networks ofcomputer systems.

In accordance with the present invention, the sender is provided with amethod and system to adaptively maintain and supervise message trafficin a manner which helps to maintain a good reputation with receivers.The method and system of the present invention works by using acombination of:

(a) message delivery disposition information (e.g., was the deliveryattempt successful, was it deferred or was it rejected outright? whatreason was given?), and

(b) internal system performance metrics to make adjustments to outboundtraffic shaping parameters (such as message delivery rate).

The method and system of the present invention can make the decision tosuspend or even abandon delivery of messages for a given recipientsystem based on these factors.

The present invention is not limited to purely reactive processing; animportant component is knowledge of acceptable traffic parameters andthe interpretation of delivery responses for well-known recipientsystems. These are handled in the present invention via an adaptivelyupdatable Rule-set that can be delivered to the sending system in anautomated fashion. The present invention may be configured to generateselected alerts in the form of a digital message (email, text message,SNMP trap and so forth, as supported by the sending system), or byexecuting a script, in the event that the system makes an adjustment ofthe configuration, based on the system configuration. For example, oneSender's administrator may only wish to be notified of suspensions orabandonment and not be concerned about increases in “message send” rate,whereas another Sender's administrator may be intensely interested inall such changes effected by the system.

Additionally, the method and system of the present invention allowsadministrative control in the form of setting additional specific limitsthat act as guard rails and in the form of an administrative overridefor traffic suspension or abandonment (i.e., termination of the E-mailsending activity to a given receiver).

The above and still further objects, features and advantages of thepresent invention will become apparent upon consideration of thefollowing detailed description of a specific embodiment thereof,particularly when taken in conjunction with the accompanying drawings,wherein like reference numerals in the various figures are utilized todesignate like components.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

FIG. 1A is a block diagram illustrating the traditional componentsincluded in a simple SMTP communications system, in accordance with thePrior Art.

FIG. 1B is a block diagram illustrating the components often included ina Relay MTA connected SMTP communications system, in accordance with thePrior Art.

FIG. 1C is a flow chart illustrating Traditional Message DeliveryWorkflow, and shows the steps that are taken by a sending system indelivering digital messages, in accordance with the Prior Art.

FIG. 2 is a flow chart illustrating Traditional Message DispositionProcessing, and shows the steps that are taken to process bothsuccessful and failed digital message delivery attempts, in accordancewith the Prior Art.

FIG. 3 is a flow chart illustrating Adaptive Delivery Workflow inaccordance with the present invention, and should be contrasted with theprocess illustrated in FIG. 1C to illustrate changes in deliveryworkflow in the present invention.

FIG. 4 is a flow chart illustrating Typical Delivery Attempt Workflow,and illustrates and expands the “Attempt Delivery” box from FIG. 1C todemonstrate some of the factors that influence the delivery processingin a sending system.

FIG. 5 is a flow chart illustrating Adaptive Message DispositionProcessing in accordance with the present invention, and should becontrasted with FIG. 2 to illustrate changes in delivery workflow in thepresent invention.

FIG. 6 is a block diagram illustrating the components included in asimple SMTP communications system, in accordance with the presentinvention.

FIG. 7 is a block diagram illustrating the components included in aRelay MTA connected SMTP communications system, in accordance with thepresent invention.

FIG. 8 is a flow chart illustrating reactive processing in the face ofgreylisting in accordance with the present invention, and shows thesteps taken by a sending system when faced with a greylisting problem.

FIG. 9 is a flow chart illustrating reactive processing for a mail blockin accordance with the present invention, and shows the steps taken whentemporarily deferred because of complaints by the receiving user.

FIG. 10 is a flow chart illustrating reactive processing for a permanentmail block in accordance with the present invention, and demonstratesthe operation of a blackhole.

FIG. 11 is a flow chart illustrating reactive processing to adjust batchsize in accordance with the present invention, and demonstrates thesteps taken when too many messages are sent in one session.

FIG. 12 is a flow chart illustrating reactive processing to adjustsending rate in accordance with the present invention, and demonstratesthe steps taken when receiver has too many recipients including thesender during a receiver specified period of time.

FIG. 13 is a flow chart illustrating reactive processing to adjustsending concurrency in accordance with the present invention, anddemonstrates the steps taken when the sender has established too manyconnections to the receiver.

FIG. 14 is a flow chart illustrating the steps taken to respond to aparticular dynamic block response, in accordance with Prior Art.

FIG. 15 is a flow chart illustrating reactive processing to a particulardynamic block response in accordance with the present invention, andrelates to the process illustrated in FIG. 14 to indicate changes in thedelivery flow in the present invention.

FIG. 16 is a flow chart illustrating IP Warmup in accordance with thepresent invention, and demonstrates some of the responses by theadaptive module based on the age of the source IP address.

FIG. 17 is a flow chart illustrating reactive processing to a responseindicating that warmup is required in accordance with the presentinventions, and shows the steps that are taken when the mail server IPhas exceeded the rate limit.

FIG. 18 is a flow chart illustrating statistics based on messagedisposition in accordance with the present invention, and shows thesteps that are taken in gathering the statistics when delivery isattempted.

FIG. 19 is a flow chart illustrating statistics on Feed Back Loop inaccordance with the present invention, and shows the steps taken ingathering the statistics when reported by the end-user.

FIG. 20 is a flow chart illustrating periodic aggregate dispositionprocessing in accordance with the present invention, and demonstratesthe behavior that results in a specific scenario.

Table 1(a)-1(c) shows an example of some of the representative rulesthat could be found in a Rule-set of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

Before explaining at least one embodiment of the present invention indetail, it is to be understood that the invention is not limited in itsapplication to the details of construction and to the arrangements ofthe components set forth in the following description or illustrated inthe application's drawings or figures. The invention is capable of otherembodiments and of being practiced and carried out in various ways.Also, it is to be understood that the phraseology and terminologyemployed herein are for the purpose of description and should not beregarded as limiting.

For example, throughout the remainder of this description, when the term“per-domain” is used, it indicates some preference or behavior that isscoped to a given recipient system. For instance, when referring toemail, “joe@example.com and bob@example.com” are two distinct recipientsthat are serviced by the same email domain (i.e., example.com). It istypically the case that the receiving system for an email domain (andindeed, for other messaging protocols) enforces the same overallreception policies at the domain level rather than for individualrecipients. When this text refers to a per-domain sending rate, itindicates a rate that applies equally to all recipients at a givendomain for all messages.

Additionally, when this text uses the term “per-binding-domain” itfurther narrows the concept of “per-domain” to scope it to a particularbinding, which may be a physical binding to a network interface oraddress or a logical binding used to segment traffic from theperspective of the sending system, but is otherwise not able to bediscerned by the recipient system. The latter case is useful more forreporting or accounting purposes of the sending system than for specificdeliverability; it is included in this description for completeness.

When this text refers to a per-binding-domain sending rate, it indicatesa rate that applies equally to all recipients at a given domain formessages associated with a given binding. In terms of a concreteexample, a sending system may be configured with multiple bindings thatmap to a number of network addresses assigned to the system. Messagesqueued to the system by “Customer A” are bound to one of thoseaddresses; whereas messages queued to the system by “Customer B” arebound to a different address. Messages from “Customer A” may be subjectto a different per-binding-domain sending rate than those from “CustomerB” based on a combination of explicit system configuration andadjustments made by this present invention. For the most part, thecontext of the rest of this text is “per-binding-domain” unless detailedotherwise.

The following description illustrates the method of the presentinvention in an exemplary context of e-mail message processing, as ameans of furnishing an example, but the present invention is alsoapplicable to all present and future digital messaging protocols, andthe scope of the present invention should not be construed as beinglimited to these illustrative embodiments. Returning to thenomenclature:

Blackhole refers to arranging for message traffic to be failed withoutattempting delivery—it is a real-time, proactive action taken to avoidthe problems that are expected to arise if the message were to be sent.This is treated as a permanent failure and logged as such.

Disposition refers to the result of a message delivery attempt.Messaging protocols allow for an explicit response code that indicatesthe degree of success, and will also provide a supplemental field toconvey additional context. For example, a system may indicate atransient rejection and specify “message permanently deferred” as partof the response. In this case, the sending system should insteadreclassify the response as a permanent failure.

D.S.N. or DSN refers to a Delivery Status Notification, and M.D.N. orMDN refers to a Message Disposition Notification. These are auxiliarymessages generated by a relaying system in order to convey informationabout the disposition or status of a message delivery attempt back tothe originator of the message. In normal operation these are sent toindicate that a permanent failure was encountered, but it is possible insome system configurations to notify the originator of events such astransient failure and successful delivery. Furthermore, some systemsallow the sender to request additional status or dispositionnotification at the time of submission of a message.

Permanent Failure or Permanent Rejection refers to a message dispositionthat indicates that the message will never be successfully delivered.Most likely causes are either due to an invalid recipient or otherreceiver policy or configuration decisions that prevent the message frombeing accepted. The two terms are from the perspective of the sender andrecipient, respectively.

Transient Failure or Transient Rejection refers to a message dispositionthat indicates that the message was not successfully delivered, but thattrying again at some later time could result in a successful delivery.Most likely causes are due to a transient resource limitation (perhapsthe system load is too high, or disk space utilization is too high), ordue to greylisting. The two terms are from the perspective of the senderand recipient, respectively.

Greylisting refers to the technique of a receiving MTA issuing atransient rejection in cases where it is unsure whether it wants toaccept the message. Classic greylisting is effectively a throttle scopedto a particular sender, recipient and sending IP triplet (see, e.g.:http://projects.puremagic.com/greylisting/whitepaper.html), but somesites employ a statistical mechanism whereby a given send attempt has achance of triggering the greylisting response.

Turning now to FIG. 3, it illustrates the Adaptive Delivery Workflow andshould be contrasted with the process illustrated in FIG. 1C toillustrate changes in delivery workflow in the present invention. In thecontext of Applicant's invention, when Applicant has decided that itwould be beneficial to do so, Applicant may set the status for a queueto be “blackhole”. The steps taken for this are:

1. Record the blackhole status and expiration time in the adaptivedelivery data store,

2. Send a notification to the administrator that a blackhole has beenenacted,

3. For each message currently in the queue that has been set toblackhole:

-   -   Record a failure due to blackhole to the appropriate logs,    -   Remove the message from the spool.

4. During reception of new messages into the system, the system willinspect the blackhole status for the queue that will be used. If thequeue status is set to blackhole, and the blackhole period has notexpired, instead of accepting delivery of the message, the System willreject the message and return an error message indicating that ablackhole is in effect. This allows Applicant to avoid paying costs forjournaling the message to spool. Applicant also logs the rejectionmessage to the appropriate logs. These steps mean that Applicant willnot attempt delivery to the destination until the blackhole status hasexpired.

FIG. 4 is a flow chart illustrating Typical Delivery Attempt Workflowand includes newly developed subject matter which supplements andimproves upon the subject matter identified in the “Attempt Delivery”box from FIG. 1C to demonstrate some of the real-time factors thatinfluence the delivery processing in the present invention's sendingsystem. The “Wait” block indicates that the system is idle pending someother externally or internally triggered action. FIG. 5 is a flow chartillustrating Adaptive Message Disposition Processing and should becontrasted with FIG. 2 to illustrate changes in delivery workflow in thepresent invention. The figure applies selected adaptive actionsspecified by the matching rule; wherein the real-time, pro-active,adaptive actions may include setting a blackhole status, setting asuspension status, adjusting shaping parameters, throttling down sendingrate to a selected limit, reclassifying disposition from permanent totransient or reclassifying disposition from transient to permanent.

The present invention generally relates an improved method for enablinga digital message system (i.e., of the type that sends digital messagesto recipients at a plurality of recipient domains) to better respond inreal-time to their inevitably encountered negative message dispositionfeedback so as to be able to still maintain high message deliverysuccess rates. The present invention accomplishes this by utilizing whatthe applicants have discovered are the best practices or rules forautomatically changing, in real-time and an ongoing manner, theoperating techniques being used by the system to deliver its digitalmessages.

In a preferred embodiment, the present invention is a method whichincludes the step of establishing and using what is herein referred toas an adaptive and continuously updatable Rule-set. It directs andchanges the system's operating techniques in an ongoing and real-timemanner so as to immediately respond to its “unsuccessful” messagedisposition” feedback and even delay the sending of a message which islikely to result in a message failure.

Without the present invention, the administrators of such digitalmessage systems have heretofore had to spend significant amounts oftheir time in taking a reactive approach (i.e., after monitoring thedelivery status of message over a specified monitoring period) toupdating their operating procedures. This often involved the task ofmaking chances after specified monitoring periods to the traffic shapingparameters, rules, etc. which are used by such systems to control howtheir digital messages are sent to various recipient domains.

One of the benefits of the Rule-set of the present invention is that itautomatically, without user or system administrator intervention, and onan ongoing or continual basis, as opposed to making periodic changes,performs this updating task for the administrator. Because of this“automatic and ongoing” feature of the present invention, we speak of itas providing a digital message sender with the ability to be proactivein responding to the “unsuccessful” message disposition informationwhich digital message senders are continually receiving.

This is a significant improvement over prior systems which were onlyreactive in the sense that they only provided for a change to a system'straffic shaping parameters or for some other specific reactive action(e.g., deferral of all future messages) when a specified maximum limitwas exceeded over a specified monitoring period for a certain systemmetric (e.g., message delivery failure rate). Prior systems had noability to take proactive action to prevent the exceeding of such systemspecified, maximum limits.

Furthermore, the present invention can make these needed updates moreaccurately and quicker than the individual administrators since thepresent invention is configured to use the “unsuccessful” messagedisposition information that it receives from a multitude of bothsending and recipient domains rather than the single recipient domainwith which an administrator is usually dealing when trying to makedecisions on how to best change its operating procedures—thus, thepresent invention is able to more quickly assemble a sufficient samplesize on which to base its updating recommendations, and therefore betterable to adapt to the feedback that digital message senders are receivingfrom their targeted recipient domains. For the above reasons, we oftenspeak of the Rule-set of the present invention as being a real-time,adaptive, updatable Rule-set.

To provide the rules of the Rule-set of the present invention with asmuch flexibility as possible so as to enable them to optimally addressthe many differing situations that can be the cause for the receipt of“unsuccessful” message disposition information and to then optimallyupdate a digital message sender's operating techniques so as to improvethe sender's ability to have their messages be successfully delivered,it proves useful to define each of such rules as consisting of a numberof parts, elements or properties. We define these as:

(a) a “code (e.g., Perl Compatible Regular Expression (PCRE) patternmatching means or similar tool)” that is compared against the“unsuccessful” message disposition feedback or response code todetermine whether a match between them exists; if it does, this matchindicates that an updating of the sender's operating techniques may bewarranted based on the “unsuccessful” message disposition feedback'sphase and the trigger for this code (see below); note that this code iseffectively a means for assessing the “unsuccessful” message deliverydisposition information so as to make a detailed assessment and decisionas to whether a change in the operating techniques of the system isneeded in order to ensure the continuation of the desired high messagedelivery success rate,

(b) the “phase” or “phase metric” of the feedback—i.e., when it was thatthis feedback was issued by the recipient domain during the process ofits receipt of the digital message (e.g., was it when the sender'ssystem was connecting with the recipient domain or after the payloadmessage had been delivered),

(c) the triggering threshold or trigger which determines the number oftimes that a specific feedback has to be received before a recommendedupdating action will be taken (e.g. the first occurrence or the firsttime that it is received at a frequency of 10/second),

(d) an updating actions or “action” that is in response to the matchingassessment (e.g., transcode, purge, suspend, blackhole, throttle,warmup, greylisted, reduce connections, reduce deliveries—for brevity,these are just listed here and defined later in the application), and

(e) a message notification or “message” (e.g., to the administrator ofthe email sending system) that alerts one regarding certain details(e.g., reason for the rule-updating action) of the updating action thatis being taken.

These various elements of any rule of a Rule-set of the presentinvention are unique and, along with the computational assessment of themessage disposition feedback, a key to providing the present method withits enhanced automatic, with user intervention, feedback control. Allprior attempts to implement automatic feedback control have required theuse of either a periodic report from the recipient domain or an inputfrom an external system in order to initiate any automatic changing of amessage delivery system's operating techniques or traffic shapingparameters or rules. The present invention requires neither of these inorder to provide its automatic features—it requires only the regular“unsuccessful” message disposition information or feedback provided bythe recipient domain. The code matching and triggering features of allrules allow them to make the necessary decisions or assessments as towhether responsive and automatic, updating actions should be takenwithout having to have any additional input from the recipient domain orany other external system.

Table 1 shows an example of some of the representative rules that couldbe found in a Rule-set of the present invention.

Turning now to the FIGS. of the present application, FIGS. 1A-1Cillustrate the components and method steps employed in traditionalE-mail transmission from a sender's terminal 100 to a recipient'sterminal 170, as discussed above.

The system and method of the present invention (as illustrated in FIGS.3-13 and 14-20) is readily implemented using traditional computing anddata transmission equipment (e.g., using hardware similar to thecomponents shown in FIGS. 1A and 1B), when programmed to perform themethod steps described below. At the outset, it is helpful to definenomenclature or terminology.

The method and system of the present invention work by modifying, eitherdirectly or via a hooking or extension mechanism, a system includingmessage sending software such that the system can monitor deliverabilityon a per-binding-domain basis; this is done by maintaining statisticsand monitoring the responses returned from the recipient as part of theappropriate messaging protocol dialogue. The system of the presentinvention also hooks the traffic shaping aspects of the sending softwaresuch that it can specify the values that will be used for those shapingparameters. There are several paths by which adjustments are made to thesending system:

Time Based:

Once a minute, each “binding-domain” (sending-IP-address andrecipient-domain combination) is assessed. If the proportion of bouncedmail is above a configurable threshold, then it is diagnosed as having adeliverability issue and is suspended. The act of suspending thebinding-domain causes an alert to be triggered. An alert may be an SNMPtrap and/or an email notification, or some other kind of messagedispatch as supported by the system (such as a text message sent viaSMS/MMS, a pager notification sent via SNPP, an Instant Message via XMPPand so forth).

Reactive:

By hooking into sending software, the method and system of the presentinvention can computationally assess and make a multi-part assessment ofthe final disposition of delivery attempts as they occur—i.e., inreal-time, rather than making an evaluation that is dependent on howmany times a certain occurrence happens in a specified monitoring periodand then taking action at the end of such a specified monitoring periodof time (see FIG. 5). The invention maintains a Rule-set of known oraccepted best practices for a number of recipient domains. Each time adelivery attempt concludes unsuccessfully, the Rule-set for therecipient domain is assessed one rule at a time, comparing thedisposition with the rule criteria. Actions specified by rule includesetting a blackhole or suspension status, adjusting shaping parameters,reclassifying disposition from permanent to transient or vice versa.

If the disposition matches, the rule is checked to see if it shouldtrigger, based on the acceptable frequency of the occurrence coded intothe rule. For instance, if a batch of 100 messages results in aparticular response 100 times in the course of 1 minute it may bedesirable to have the action associated with the rule trigger only onceinstead of 100 times.

If a rule is deemed to have “matched” and so is triggered, one or moreof the following actions can be taken:

Suspend the sending-IP-recipient-domain combination for a period oftime, preventing it from being attempted for delivery until thesuspension is lifted. An alert is triggered for a suspension, asdescribed above.

Cause mail associated with the sending-IP-recipient-domain combinationto be discarded without further delivery attempts for a period of time(Blackhole). An alert is triggered when this rule is enacted, asdescribed above.

Increase or decrease overall traffic shaping rules by one step for thesending-IP-recipient-domain combination. These are used described in thejust-in-time section below.

Adjust the retry interval for the sending-IP-recipient-domaincombination to handle a greylisting response from the recipient site.Greylisting is a technique used by receivers when they are unsure abouta sender; it results in mail being delayed until a later time. Theinvention adjusts the retry interval such that retries are made more orless aggressively depending on the content of the greylisting response.For instance, if the response indicates that greylisting is beingapplied for the next 30 minutes, the retry interval will be adjusted tomatch that, as a more aggressive schedule may result in bad reputation,and a less aggressive schedule will result in longer delays than arenecessary.

Adjust the age of the sending-IP address. The age is used as a parameterin the just-in-time section below.

Adjust a specific traffic shaping parameter by a specified amount(positive or negative). Possible parameters are listed below.

Re-interpret a transient rejection response as a permanent rejectionresponse.

Re-interpret a permanent rejection response as a transient rejectionresponse.

Just in Time/Proactive:

The invention hooks into the email sending system such that it canoverride configuration values as they are evaluated. For instance, whendetermining the number of connections that should be established to arecipient domain for a given sending-IP-address, the invention isinvoked and is able to make a traffic shaping adjustment at that time,if it necessary.

The system and method of the present invention use this vector to assesswhether it should make a proactive adjustment to the shaping parameters.This adjustment can be made based on the information collected for thebinding, and can be either a positive or a negative adjustment. In anexemplary embodiment, Applicants have implemented a very simplealgorithm that increases the shaping parameter by one positive incrementif we have not made a negative adjustment in the past hour(configurable).

Proactive adjustments are throttled such that the system will not makemore than one adjustment for a sending-IP-recipient-domain combinationin a given minute interval (configurable). This prevents the system fromrapidly increasing its parameters to the point where it would cause adeliverability issue; by slowly stepping in the changes, the system canreact to the disposition returned from the receiving domain and correctthe action before it becomes a serious problem.

Running just-in-time avoids expensive configuration adjustments thatwould be required if the logic behind the adjustments was run as aperiodic assessment; there are a large number of traffic shapingparameters and with customers using several thousand IP addresses tosend to 50,000 domains, the processing required for assessing the statusof the system would become computationally prohibitive.

The effective configuration value can be expressed in a parametric form,such that the value can be computed based on a rule-defined function. Weuse this form to express rules such as “new IP addresses should limittheir send rate to X per hour until they have sent Y messages, at whichpoint they can increase to Z messages per hour”. These rules are usuallyderived from accepted best practices for well-known receivers.

User Configuration or Interaction:

The invention was built such that a system administrator can overridethe actions of the invention to by configuring guide rails (upper andlower bounds) for each configuration option that the invention adjusts,as well as being able to selectively enable or disable the adaptivedelivery capabilities on a per sending-IP-recipient-domain combination.

The invention provides interactive commands via a command console toallow the administrator to introspect or clear the state of the trafficshaping parameters. The console also provides the ability to list andoverride suspensions or blackholes triggered by rulesets.

A daily report email is generated that summarizes the deliverability andparameters for the administrator.

Parameters:

The invention specifically makes adjustments to the followingparameters, although the technique can be generally applied to any ofthe systems parameters that affect load and resource management. Thevalues may be scoped globally or on aper-sending-IP-per-recipient-domain basis, or some combination thereof,such that overrides put in place can be specified once for a givenrecipient-domain (or even globally) without having to be specifiedexplicitly for each possible sending IP address (as they may number intoin the thousands). A description of the parameters as they apply toApplicant's system is supplied to aid the reader in understanding thenature of the parameters; the invention is not specifically limited tooperating with parameters that have precisely the same meaning.

Max_Deliveries_Per_Connection—the number of deliveries attempted on agiven TCP connection before closing the connection

Max_Outbound_Connections—the number of concurrent connections permittedfor a given recipient domain

Outbound_Throttle_Messages—the maximum rate at which messages may besent

Max_Recipients_Per_Connection—the maximum number of recipients permittedto be sent on a given TCP connection before closing the connection.Similar to Max_Deliveries_Per_Connection, but takes into account thefact that email messages may be addressed to multiple recipients in abatch email.

Max_Recipients_Per_Batch—the maximum number of recipients permitted tobe sent as part of a batch email send for a given message. Messages thathave more than this number of recipients are broken up into smallerbatches.

Idle_Timeout—the time period to keep a connection open to givenrecipient domain address after the sending queue has been exhausted. Theconnection may be re-used within this time period to reduce the overheadof re-establishing the connection if more mail arrives for thatdestination.

EHLO_Timeout—the time period that the sending system will wait for aresponse from the recipient system when waiting for the SMTP “EHLO”response.

MailFrom_Timeout—the time period that the sending system will wait for aresponse from the recipient system when waiting for the SMTP “MAIL FROM”response.

RCPTTO_Timeout—the time period that the sending system will wait for aresponse from the recipient system when waiting for the SMTP “RCPT TO”response.

BODY_Timeout—the time period that the sending system will wait for aresponse from the recipient system when waiting for the SMTP “DATA”response.

RSET_Timeout—the time period that the sending system will wait for aresponse from the recipient system when waiting for the SMTP “RSET”response.

Retry_Interval—the base time period which should elapse beforere-attempting delivery of a message that was transiently rejected by therecipient. In Applicants system, this time period is appliedexponentially with each additional retry until the message expires fromthe system.

Max_Retries—the maximum number of delivery attempts before determiningthat a message will never be accepted and thus be expired from thesystem.

Max_Resident_Active_Queue—the maximum number of messages to be committedto RAM for a given recipient domain queue. If the volume of messages inthe queue exceeds this number, the excess messages are put into a lowerresource consumption mode that requires a disk access before they can besent.

Thread Pool size—Applicant's system uses a number of pools of threads tocarry out certain tasks. The optimal number of threads for a givensystem depends on the workload, which in turn can vary over time.

Outbound_Throttle_Connections—the maximum rate at which new connectionsmay be established

Inbound_Throttle—the maximum rate at which new messages are allowed intothe system

Max_Resident_Messages—the maximum number of messages that can becommitted to RAM for the system overall, as opposed to theMax_Resident_Active_Queue which is the per recipient domain value.

Max_Retry_Interval—caps the effective retry interval value whencalculating the interval based on the number of attempts and theRetry_Interval

Metrics/Consumed Information:

The following metrics/information are fed into the invention and caninfluence its actions in Applicant's current implementation:

Message disposition for permanent and transient failure responses

Permanent failure rate for the binding-domain expressed as a percentageof delivery attempts over the last hour

The age of a binding (IP address), expressed as time since the addresswas first used.

The following metrics/information can be consumed by the invention:

Average delivery time in seconds over the last hour

Average length of time taken to dispatch a job to a particular threadpool over the last hour.

Implementation:

The invention is implemented in two parts; a module written in the “C”language that hooks into the email system internals and a module writtenin the “Lua” language that implements the majority of the algorithms.The latter part is implemented in “Lua” so that the rule-sets updatemechanism can be implemented without the need to deliver compiled objectfiles that are system specific. This implementation choice is not afundamental requirement of the invention, but a convenience forApplicant's software delivery mechanism in that it reduces overheads fordevelopment and deployment of revised rules.

Initialization:

The adaptive module initializes by attaching hooks to monitor messagedisposition and override the effective value of configuration parametersas listed above in the paragraph entitled “Parameters.” It also arrangesto run a periodic task known as the “bounce sweep” at an intervalspecified by the Bounce_Sweep_Interval parameter; this defaults tohourly. The adaptive module maintains its state in a data storagemedium, such that a process or system restart does not cause it to loseits settings.

Bounce Sweep:

The purpose of this task is to periodically (based on theBounce_Sweep_Interval parameter) iterate each binding-domain (distinctsource IP address and recipient domain), and if adaptive tuning isenabled for that binding-domain (as controlled by the Adaptive_Enabledparameter), and if the number of delivery attempts exceeds the valuespecified by the Adaptive_Attempt_Threshold parameter (default 100),examine the sending failure rate expressed as the number of failuresdivided by the number of attempts.

If the failure rate exceeds the value specified by theAdaptive_Rejection_Rate_Suspension_Percentage parameter (default 10%),and if no other adaptive adjustments have been applied within the periodspecified by the Adaptive_Adjustment_Interval parameter (default 60seconds), then the binding-domain is suspended as detailed in theparagraph entitled “Suspend Domain”, for a duration specified by theAdaptive_Default_Suspension parameter (default 4 hours).

A future implementation of the invention will apply similar rules andprocessing around the transient failure rate.

Fine Grained Assessment Based on the Classification of DeliveryFailures:

The ultimate cause of a failed delivery attempt can be one of manyvaried reasons, some more serious than others, from the perspective ofmaintaining a good sending reputation (for example, a high volume ofinvalid recipient address responses can lead to the sender beingblocked).

In applicant's preferred embodiment, a standard bounce classificationfacility analyzes the protocol level responses and classifies them intoone of a number of possible broad reasons, such as “mailbox is full”,“message too large” and so forth. In Applicant's embodiment, theclassification system is supplied with some system definedclassification codes, and a facility that allows a local administratorto define and expand rules that will classify new and varied responsesto match the system defined codes. Furthermore, the same facility allowsthe local administrator to define new classifications. Eachclassification is identified by a classification code, which happens tobe a numeric code in Applicant's implementation, but could also be someother identifier.

Applicant's preferred embodiment of the Adaptive Delivery facility is torecord the incidence of each classification code as protocol level (suchas SMTP) responses are received. These classification codes are trackedhistorically such that the volume of any particular classification codeencountered for a given binding-domain over the time period specified bythe Bounce_Sweep_Interval parameter are known to the system.

The Bounce Sweep task, in addition to the basic processing described inthe paragraph entitled “Bounce Sweep”, can be configured to act upon therates of bounce classifications passing defined thresholds by definingrules that have the following attributes:

A list of the bounce classification codes

A low threshold, expressed as a percentage

A high threshold, expressed as a percentage

An action to be triggered when the low threshold is crossed

An action to be triggered when the high threshold is crossed

The Bounce Sweep task will assess the rules that are defined for a givenbinding-domain, as controlled by the Adaptive_Enabled parameter, usingthe following logic:

define a volume counter and initialize its value to 0

define an attempts counter and set it to the number of delivery attemptsmade by the current binding-domain over the prior Bounce_Sweep_Intervaltime period

compare the value of the attempts counter with theAdaptive_Attempt_Threshold parameter (default 100). If the attemptscounter is less than the attempt threshold, stop processing the currentrule and continue processing with subsequent rules.

For each bounce classification code listed with the rule, retrieve thevolume of failures classified with that code and add that value to thevolume counter that was initialized in the first step

-   -   compute a rate percentage by dividing the volume counter by the        attempts counter    -   if the rate percentage is greater than or equal to the value of        the high threshold parameter, then apply the action specified by        the high threshold action parameter and stop processing the        current rule, continue processing with subsequent rules.    -   if the rate percentage is greater than or equal to the value of        the low threshold parameter, then apply the action specified by        the low threshold action parameter and stop processing the        current rule, continue processing with subsequent rules.

The action referred to in the description of the high/low thresholdactions above can be any one of the actions listed in the paragraphentitled “Disposition Processing”.

The system is pre-configured with a rule with the following parameters:

Classification codes: “hard bounce”, “mailbox full”, “message too big”

low threshold 3%

low action (“throttle” “down”)

high threshold 10%

high action (“suspend” “4 hours”)

This has the effect of slowing down the sending rate once the combinedtotal of failures classified as “hard bounce”, “mailbox full” or“message too big” exceeds 3%, and suspending the mail flow when thisrate reaches 10%.

There may be multiple rules, and those rules can be expressed on abinding-domain basis by the local administrator.

Abuse Feedback Loop Processing:

The (prior art) open standard for complaint feedback loop processing isa feedback loop (FBL), sometimes called a complaint feedback loop, andprovides an inter-organizational form of feedback by which an Internetservice provider (ISP) forwards the complaints originating from theirusers to the sender's organizations. ISPs can receive users' complaintsby placing report spam buttons on their webmail pages, or in their emailclient, or via help desks. The message sender's organization, often anemail service provider, has to come to an agreement with each ISP fromwhich they want to collect users' complaints. As an alternative, abusecomplaints may be directly sent to addresses where such feedback mightbe received. Target abuse mailboxes can be assumed to be in the formdefined by RFC 2142 (abuse@example.com), or determined by queryingeither the regional Internet registry's whois databases—which may havequery result limits—or other databases created specifically for thispurpose.

The receiving sites that implement FBL processing have very stringentrequirements on the volume of complaints that are issued against a givensender; it is not uncommon for a sender to be blocked if less than 1% oftheir messages result in complaints. As such, it is important to reactto FBL information as quickly as possible.

In accordance with the present invention, a preferred embodiment has afacility that recognizes FBL report message payloads (as described byRFC 5965) and records their incidence in a similar fashion to thatdescribed in the paragraph entitled “Fine Grained Assessment Based onthe Classification of Delivery Failures” above, except that it does soover a separate, longer, time period known as the FBL_Sweep_Period. Thedefault for this parameter is 24 hours.

The Bounce Sweep task, in addition to processing the rules in theparagraph entitled “Fine Grained Assessment Based on the Classificationof Delivery Failures” above, processes a very similar of rules that arespecific to FBL. The rules have similar attributes:

A list of the applicable FBL report types (eg: abuse, fraud, virus,other)

A low threshold, expressed as a percentage

A high threshold, expressed as a percentage

An action to be triggered when the low threshold is crossed

An action to be triggered when the high threshold is crossed

The logic for evaluating and acting upon these rules is similar to thatdescribed in the paragraph entitled “Fine Grained Assessment Based onthe Classification of Delivery Failures”, except that instead of usingthe Bounce_Sweep_Interval as the time period used for assessing thevolume, the FBL_Sweep_Period is used. It is important to note that thislogic is still evaluated every Bounce_Sweep_Interval, such that thepreferred embodiment in its default configuration assesses the FBL rulesevery hour, but acts upon rate data collected over the preceding 24hours.

Applicant's preferred embodiment provides a default setting for thisrule:

All FBL report types

low threshold 0.2%

low action (“throttle” “down”)

high threshold 0.5%

high action (“suspend”, “4 hours”)

This has the effect of slowing down mail, perhaps stepping down thethrottle multiple times, while a significant volume of FBL reports arediscovered, with the intention of ultimately suspending delivery priorto the receiver enacting a mail block.

Suspend Domain:

The purpose of this task is to cease delivery attempts for a particularbinding-domain (distinct source IP address and recipient domain) forspecified time duration.

This task will trigger a notification with the message “suspending for<duration>” as detailed in the paragraph entitled “Notify”.

It will then record in the adaptive module state that the binding-domainis subject to suspension for the requested duration. It will not alteror extend the state of a suspension that may already be in place.

Finally, it will clear the adaptive tunings it has put in place as partof Configuration Modification.

Notify:

The purpose of this task is to notify the administrator that an eventtook place. When invoked, the triggering binding (sending IP), domain(recipient domain), rule, triggering disposition information anddescriptive text are passed in as parameters. To avoid repeatedlysending the same notification in a short time span, the notify routinethrottles the notification such that for a given set of triggeringcriteria (based on the parameters passed in above), no more than 1notification is generated in each interval specified by theAdaptive_Notification_Interval parameter (default 1 hour).

When a notification is generated, the implementation will generate anemail message payload (which may be routed out of this system via someother protocol, such as SMPP, as dependent on the system configuration)addressed to the recipients specified by theAdaptive_Alert_Email_Destination parameter (must be configured by thesystem administrator) and sourced from the address specified by theAdaptive_Alert_Email_Sender (default is the NULL sender address, whichcannot be replied to).

The notification message payload includes the text:

This is an alert generated by the Adaptive Delivery Component.

The alert pertains to:

-   -   Domain: <DOMAIN>    -   Binding: <BINDING>    -   Host: <HOSTNAME-OF-THE-MACHINE-GENERATING-THE-ALERT>

It also includes the triggering information in the message payload, aswell as the descriptive text. For example, in the case of a domainsuspension, the descriptive text will be “suspended for <DURATION>”. Thesubject of the notification message is formatted as:

-   -   ALERT: <BINDING>/<DOMAIN> on        <HOSTNAME-OF-THE-MACHINE-GENERATING-THE-ALERT>.

Alternatively, notifications may be to be sent in the form of an SNMPtrap.

Configuration Modification:

In Applicant's implementation, the Adaptive Delivery module performs thebulk of the parameter adjustments by hooking into the configurationsystem, such that it can modify the effective values of the systemparameters. We chose to do this rather than change the actual configuredvalue for two reasons. The first is that application of a changedconfiguration can have some heavyweight processes associated with it tovalidate overall configuration consistency and potentially invalidatecached information. In short, regular adaptive tunings can potentiallynegatively impact performance if they are implemented in this way inApplicant's system. The second reason for implementing as a reader-hookis that it allows the value to be computed parametrically at the time itis needed. This allows powerful rules to be expressed.

This section of the text details the steps that are taken to determinethe effective value of a parameter at the time it is needed.

For a given configuration parameter, the Adaptive Delivery hook isinvoked and passed the configured value specified by the user in theconfiguration file, the name of the parameter being interrogated and thebinding-domain information (the source IP address and recipient domain).It is important to note that the system supports both binding-domainspecific configuration and binding specific configuration. When anoption is being queried at the binding level, no domain will be passedto the interrogation function.

If the parameter is Suspend_Delivery or Blackhole, and the configurationsystem indicates that the parameter is disabled (indicating that trafficshould flow as usual), the Adaptive Delivery data store is consulted todetermine if a Suspension or Blackhole (respectively) is in effect. Theresult of this consultation is used as the effective value for theseparameters, and further processing for them stop here. The rest of thissection details what happens to the other parameters.

If the parameter is not Suspend_Delivery and not Blackhole, then theadaptive “guide rail” values are determined by obtaining the value ofthe parameter named “Adaptive_<PARAMETERNAME>”. For example, if theparameter currently being interrogated is “Max_Outbound_Connections”,then the value of the “Adaptive_Max_Outbound_Connections” parameter isexamined to determine acceptable lower and upper bounds for the range oftuning. There is no default value for these guide rail values; if theyare not explicitly configured then there is deemed to be no useroverride for the parameter tuning.

If there is no user-specified guide value, the Rule-sets are consultedaccording to the following logic:

1. If the Rule-set defines an alias for the specified domain,re-interpret the domain as though it was specified as the alias andrepeat, until we have arrived at a canonical Rule-set, or a domain withno specified rules. This allows for a single set of rules to be definedfor a site that has many distinct top-level-domains (TLDs). An exampleof this is Yahoo!; they have many different top-level domains toestablish their presence in many different territories. If no domain wasprovided to this interrogation function, treat the domain as though itspecified the global wildcard Rule-set named “*”.

2. If a Rule-set is defined for the domain specified by the result ofstep 1, proceed to step 4.

3. This step transforms a name of the form subdomain.example.com to apattern string of the form “*.example.com” (a wildcard Rule-set). If arule-set is defined for this modified name, proceed to step 4. It isimportant to note that this step does not perform an actual wildcardmatch, it is checking to determine if there is a wildcard Rule-setdefined. If no wildcard Rule-set is defined, this step repetitivelystrips off the node name from the left hand side until it either finds adefined wildcard Rule-set or arrives at the global wildcard rule-setnamed “*”. If the domain to be interrogated is “subdomain.example.com”then the following set of Rule-set names, in this specified order, willbe searched and the search will stop at the first defined rule-set:“subdomain.example.com”, “*.example.com”, “*.com”, “*”.

4. Given a Rule-set from step 2 or 3 above, the rule-set is examined todetermine if it defines a configuration guide for the configurationvalue being interrogated. If it does not, and we arrived here as part ofa search from Step 3, the search is continued until we arrive at arule-set that does define a guide or until there are no more Rule-setsto examine.

At this point, we have either a guide value specified by the systemadministrator from the configuration file, or the most specific guidevalue for the binding-domain of interest as specified in the Rule-sets,or no guide value.

If no guide value is found, then it is deemed that no adaptive tuning isallowed and the configured value for the parameter it returned to thesystem. Otherwise, the following steps are taken:

1. The age of the binding (sending IP) is determined. If the adaptivedelivery module has never observed the binding before, the current timeis recorded as the “birth date” for the binding and will be used as thebasis of subsequent binding age determination and processing moves toStep 5.

2. Otherwise (the binding is already known to the adaptive module), therecorded value for the parameter being interrogated, the last_changetime for that parameter, and the number of messages sent to the domainfrom the binding are looked up from the adaptive delivery data store.

3. Determines if the value for the parameter being interrogated shouldbe adjusted. If the binding-domain is suspended, the value will not beadjusted. If it is not suspended, and the last_change time is more thanthe value of the Adaptive_Positive_Adjustment_Interval parameter(default 1 hour) and if no other adjustments have been applied for thisbinding-domain within the time interval specified by theAdaptive_Adjustment_Interval parameter (60 seconds), then the value issubject to adjustment.

4. If the value is subject to adjustment, the current implementationsimply increases the value by adding 1 to it (future implementations mayuse larger values, perhaps scaled according to the range of the guidevalues, or even negative values, based on related metrics, such asobserved message throughput changes over time, average time for deliverychanges over time and outgoing bandwidth utilization from the source IPto the recipient domain changes over time).

5. At this point, we have arrived at a value for the parameter thatstarted at the number configured in the configuration file, and that mayhave been subject to adjustments per the rules above. The next step isto apply the guide value that was determined based on the recipientdomain.

-   -   a. If the guide value is a pair of values, it is interpreted as        lower and upper bounds for the value. If the binding is new (we        arrived here from step 1), we treat the effective value as that        specified by the lower bound in the guide. Otherwise, the        possibly-adjusted value is clipped such it is not less than the        lower bound and not greater than the upper-bound specified by        the guide.    -   b. If the guide value is a numeric value, it is used as a single        fixed value that cannot vary; it overrides the user-specified        configuration (if any) for the parameter being interrogated.    -   c. If the guide value is a function type, it is a parametric        guide and is invoked, passing the possibly-adjusted value, the        age of the binding (expressed as time since the birth-date        recorded in Step 1), and the number of messages sent to the        recipient domain from that binding. The return value of the        parametric guide function is used as the new adjusted parameter        value.

6. If the value for the parameter was adjusted as part of the aboveprocessing, it is stored in the adaptive delivery data store, so that itis recorded and available in the event of a process or system restart.

7. The possibly-adjusted value for the parameter is returned to theinterrogator.

Applicant's implementation employs a cache such that all of theprocessing described in this section is triggered at most once in every60 seconds (this can be adjusted via the Adaptive_Cache_TTL parameter).

Disposition Processing:

In reference to FIG. 5, the following text describes in detail theactions taken by the adaptive system during message dispositionprocessing. These actions are triggered at the point where the systemhas attempted delivery of a message and the destination system hasreturned an error code and a supplemental description. In the context ofSMTP, this will be of the form “250 OK” for a successful delivery, “452user over quota” for a transient failure (in this case indicating thatthe recipient mailbox is full) or “550 no such user” for a permanentfailure (in this case indicating that the recipient is not known at thataddress).

For reference, the SMTP protocol is described in RFC 5321 (see, e.g.,http://www.rfc-editor.org/rfc/rfc5321.txt) and defines the numeric codesmentioned above. The SMTP reply codes are augmented by a widely adoptedstandard for enhanced status codes described in RFC 1893 (see, e.g.,http://www.rfc-editor.org/rfc/rfc1893.txt) that includes a machinereadable auxiliary code in the supplemental description. For example,the “user over quota” response called out above could be returnedinstead as “452 user over quota” to positively indicate to the senderthat the mailbox was indeed full, as distinct from a generic systemstorage exceeded status implied by the 452 reply code.

This description focuses on SMTP as a means of illustrating theinvention, but the method of the present invention is not limited toSMTP; other message delivery protocols have analogous concepts and mapto this scheme. It should also be noted that Applicant's implementationcurrently maps these other protocol responses to equivalent SMTPresponses.

The following steps are taken when assessing the disposition ofmessages; the context of this evaluation includes the message itself aswell as the routing information for that message. That routinginformation includes the destination or recipient domain for themessage, as well as the binding (Source IP) to which the message isattached. This section refers to these items as domain and binding,respectively.

In Applicant's implementation, there are certain internally triggeredevents that will cause these rules to be triggered, but where adaptiveprocessing is not required. The first example of this is at processstart-up; if there are messages in the spool that are past theirexpiration time, the system will treat them as permanent failures andtrigger the adaptive processing. Applicant's implementation specificallyshortcuts the adaptive processing in this case and instead takes theusual permanent failure processing path through the system.

If the parameter Adaptive_Enabled is set to false for the binding-domainpair from the routing information, the adaptive processing is skippedand regular disposition processing continues.

Next, a Rule-set for the domain is determined by applying similar logicto that described in the paragraph entitled “ConfigurationModification”:

1. If the Rule-set defines an alias for the domain, the domain isre-interpreted as the target of that alias, recursively until we areleft with a domain that does not have an alias defined for it.

2. If the Rule-set defines disposition rules for the domain, we havefound the rule-set for that domain and processing of those rulescontinues as described below this set of numbered bullet points.

3. If no disposition rules are defined for the domain, the domain isre-interpreted according to the following sequence, such that if awildcard or higher-level hierarchy domain has rules defined, those ruleswill be used. If the domain is subdomain.example.com, it is interpretedas the following sequence of domains, one after the other, until amatching Rule-set is located: “*.example.com”, “*.com”, “*”, or when thedomain name is “*” and no Rule-set is located

If there is no disposition Rule-set defined for the domain, then nofurther adaptive processing is performed, and regular dispositionprocessing continues. Otherwise, the disposition rule-set is processedby iterating over the defined rules, in the order they were defined.

Transcode Action:

Cause the regular disposition processing to treat the message as thoughthe delivery attempt resulted in a different outcome. For instance, somesites will return a response such as “451 mail permanently deferred”,which is a transient response. This results in the messages beingretried by the sender until they expire. This action accepts the newstatus code as its argument.

A transcode rule allows the response to be re-interpreted as a permanentfailure instead, resulting in a reduction in load on the sending systemand a reduction in bandwidth usage to the recipient site. An exampletranscode rule definition is shown in Table 1.

This rule causes the “421” to be replaced with “554”, and a blackhole tobe established. A notification will be triggered with the descriptivetext “Remediation with Yahoo required”. This action is triggeredimmediately on detection of the “ . . . permanently deferred” responsemessage when it occurs at connection time.

Purge Action:

The purge action causes the messages in the queue for the binding-domain(source IP and recipient domain for the message being examined) to bepurged.

This action accepts a failure reason as its argument. Each message inthe applicable queue is treated as though it failed due to the failurereason argument passed to this action.

Suspend Action:

This action triggers the suspension activity as described in theparagraph entitled “Suspend Domain.”

The action accepts a time duration as its argument; this is used tospecify how long the binding-domain should be suspended. An examplesuspension rule is shown in Table 1.

This example will trigger a suspension if the “temporarily deferred”pattern specified by code is matched 5 times in the space of 1 second;when it does, message flow is suspended for a period of 4 hours.

Blackhole Action:

The blackhole action enables blackhole mode for the specifiedbinding-domain. Reference FIG. 4; when a blackhole is enabled, theregular delivery workflow is altered such that instead of deliveringmail, the mail is instead treated as failed without making a deliveryattempt.

Similar to the suspension processing (See the paragraph entitled“Suspend Domain”), this action will trigger a notification with themessage “blackholing for <duration>” as detailed in the paragraphentitled “Notify”. It will then record in the adaptive module state thatthe binding-domain is subject to blackhole for the requested duration.It will not alter or extend the state of a blackhole that may already bein place.

In the method of the present invention, when it would be beneficial todo so, the system may set the status for the adaptive module used with aqueue to “blackhole”. The steps taken for this are:

1. Record the blackhole status and expiration time in the adaptivedelivery data store

2. Send a notification to the administrator that a blackhole has beenenacted

3. For each message currently in the queue that has been set toblackhole:

-   -   Record a failure due to blackhole to the appropriate logs    -   Remove the message from the spool, and

4. During reception of new messages into the system, the system willinspect the blackhole status for the queue that will be used. If thequeue status is set to blackhole, and the blackhole period has notexpired, instead of accepting delivery of the message, the system willreturn an error message indicating that a blackhole is in effect. Thisallows the system's users to avoid paying 10 costs for journaling themessage to spool. The system also logs the rejection message to theappropriate logs. These steps mean that the system will not attemptdelivery to the destination until the blackhole status has expired.

Throttle Action:

As illustrated in FIG. 12, the throttle action makes an adjustment tothe traffic shaping parameters such that the sending rate is adjusted ina direction specified the parameter passed to the action.

Applicant's implementation currently only supports throttling “down”,but it is envisioned that there may be some circumstances wherethrottling “up” is desired. The throttle action takes the followingsteps:

Triggers a notification that the throttling parameters are beingadjusted, per the paragraph entitled “Notify”, with the informationaltext “adjusting throttle <DIRECTION>”. When throttling “down”, thecurrent (possibly-adjusted via the paragraph entitled “ConfigurationModification”) value of the Outbound_Throttle_Messages parameter(default is not specified; a given rule-set may establish a bestpractice default, and this may be adjusted via the paragraph entitled“Configuration Modification”) will be reduced by 10%. IfOutbound_Throttle_Messages is explicitly configured to be unlimited, thethrottle action has no effect.

Warmup:

The warmup action causes the age (in seconds) of the binding (source IP)to be set to the value specified by the action parameter. The concept ofIP Warmup is that many well-known receiving sites have establishedpolicies around the volume of messages that they want to see from agiven sender, and that these policies are often time based, resulting ina relatively low allowed throughput in the first two weeks (for example)of the IP being established, and ramping up over time after that point.

The adaptive module implements these policies via parametricconfiguration guides, as described in the prior paragraph entitled“Parameters.” One of the parameters used in these guides is the age ofthe binding.

An example warmup rule is shown in Table 1. This rule cases the age ofthe binding to be reset to 1 second when a connection attempt results inthe text above being returned.

Greylisted Action:

The greylisted action is intended to be applied in situations wheregreylisting is detected. The intention is to tune the retry time suchthat the next delivery attempt will be made at the “right” time withoutunnecessary delivery attempts before we know that the receiver site iswilling to accept the message.

In the current implementation, the greylist action expects a timeduration as its parameter. This specifies the revised retry interval. Afuture implementation might instead extract the duration from thedisposition itself.

When the greylist action is invoked, the current (possibly adjusted, perthe paragraph entitled “Configuration Modification”) value for theRetry_Interval parameter is determined. If the parameter value is lessthan the time duration parameter passed to this greylist action, theRetry_Interval parameter will be adjusted upwards to match thegreylisting duration.

Additionally, the (possibly adjusted, per the paragraph entitled“Configuration Modification”) value for the Max_Retry_Interval parameteris determined. If the parameter value is less than a reasonable numberderived from the greylist duration (in the current implementation, weuse 4 times the greylist duration), then the Max_Retry_Intervalparameter is adjusted upwards to match the reasonable number (4 timesthe greylist duration).

An example greylisting rule is shown in Table I.

This is a rather generic match that triggers the greylisted actionwhenever the disposition text contains the string “grey list”,“Greylist”, “Grey list” or “grey list”.

Reduce Connections Action:

The reduce connections action expects as its parameter a delta that willbe applied to the Max_Outbound_Connections parameter.

When invoked, the (possibly adjusted, per the paragraph entitled“Configuration Modification”) value for the Max_Outbound_Connectionsparameter is determined, and the delta value is subtracted from it. Ifthe resultant value is less than one, then it is clamped to have a lowerlimit of 1. This adjusted value is then used in the future when thesystem interrogates the value of the Max_Outbound_Connections parameter,as described in the paragraph entitled “Configuration Modification”,above.

Reduce Deliveries Action:

The reduce deliveries action expects as its parameter a delta that willbe applied to the Max_Deliveries_Per_Connection parameter.

When invoked, the (possibly adjusted, per the paragraph entitled“Configuration Modification”) value for theMax_Deliveries_Per_Connection parameter is determined, and the deltavalue is subtracted from it. If the resultant value is less than one,then it is clamped to have a lower limit of 1. This adjusted value isthen used in the future when the system interrogates the value of theMax_Deliveries_Per_Connection parameter, as described in the paragraphabove entitled “Configuration Modification.”

System Diagrams:

FIG. 6 is a system block diagram illustrating an implementation of thesystem of the present invention 200. The sender user sends a digitalmessage from a sender terminal 100 intended for a receiving user. Themessage is sent through a user agent 120 which places the message into aqueue of mail to be sent. The adaptive module of the present invention220 is accessed to analyze the message based upon the configurations setby the system administrator for the binding-domain pair from the routinginformation. The message is then transferred to the client MTA 140 whichtransfers the message to the server MTA 150. The server MTA 150 placesthe message into a queue for delivery to the receiver's user agent 160.User agent 160 receives the message and makes it available for thereceiver user at a receiver terminal 170.

Referring now to FIG. 6, user 100 and user agent 120 may be anindividual person sitting at his or her computer using MicrosoftOutlook, but “user” and “user agent” should not be limited to thatexample. A message injector is an automated system for automaticallygenerating one or many commercial or non-commercial e-mails or digitalmessages. Messages automatically generated by a message injector couldbe automatically generated as a batch of merged message content with aplurality of selected addresses or in response to a selected event suchas a message recipient's purchase. Thus, 100 may be a user configuringthe batch parameters of the message injector, where examples of batchparameters include message content, overall list of recipients, and 120can be an automated user agent which transmits a configured set ofmessages in response to the user's parameters.

FIG. 7 is a system diagram illustrating an implementation of the presentinvention that involves relaying. Similar to the system 200 of FIG. 6,the sender user sends a digital message which is sent through a useragent. The user agent places the message into a queue of mail to be sentand it is analyzed by the adaptive module of the present invention. Themessage is then transferred to the local MTA, which instead of passingit directly to the receiving host's local MTA, it is passed to a RelayMTA. The Relay MTA places the message into a queue of mail beforerelaying the message across the internet between at least one otherRelay MTA. The Relay MTA transfers the message to the receiving host'slocal MTA. The local MTA places the message into a queue for deliver tothe receiver's user agent. The user agent receives the message and makesit available for the receiver user at a terminal.

The prior art message systems (e.g., as illustrated in FIGS. 1A, 1B and1C) deal with the transfer of messages from one system to another bymeeting the minimum requirements of the various specifications. That is,those systems are designed to receive the transmission of the messages,correctly storing them to the local disk (also known as spooling), andthen working through the backlog of messages stored to the spool anddelivering them on to the next hop.

This approach tends to be controlled, in most Message Transfer Agent(MTA) software, by a handful of parameters that affect the number ofconcurrent connections and overall message sending rate. Theseparameters are typically configured explicitly by a local administratorin response to the demands of their mail flow and, in the case of largerscale senders, based on the feedback from the recipients of that email.In the modern age of communication, the majority of email recipientsshare the same service providers (e.g., AOL.sup^(SM), Hotmail.sup^(SM),Gmail.sup^(SM), Yahoo.sup^(SM) and so on), which means that theoperators of those services are looking to find ways to manage theinflow of mail to reduce load on their systems and to reduce theincidence of Spam complaints.

As noted above, one of these techniques is known as “Greylisting”. Oneof the capabilities of the SMTP is the concept of a Transient Failure (anumeric code in the range 400-499) which indicates to the sender thatthey should requeue the message and try again later. Transient Failuresare intended to reflect issues such as the system load on the receivingsystem being above some locally defined limit, or that the local systemhas exceeded a configured disk quota limit.

Greylisting takes advantage of the transient failure to reflect localpolicy choices rather than local resource issues. The prime example isthat the receiver decides that they don't know enough about thereputation of the sender to make a decision about whether they want toreceive the message; they are not on a blacklist (a list of knownundesirable senders) and nor are they on a whitelist (a list of knowngood senders) but they are suspicious of the reputation. In this greyscenario, the receiver can opt to issue a transient failure, causing thesender to requeue the message and try again later, rather than thereceiver taking a chance of relaying unwanted content through to therecipient.

Greylisting works well for receivers because it uses less of the highcontention resources (the disk and CPU) and reduces the risk of relayingbad content. Some spam senders use special software, known in theindustry as Ratware, that is either poorly engineered or deliberatelyengineered not to follow the precise details of the SMTP specification.One feature of ratware for the serious spam software is that it will notrequeue messages if it encounters a transient failure response; it willsimply move on to the next address in its list of addresses. Greylistingcan effectively block a larger amount of this type of ratware generatedspam.

Even if the messages that are greylisted are retried later on, there isstill benefit to greylisting from the receiving side; in the time sincethe message was originally seen by the receiver, there may now be anupdated antivirus or antispam Rule-set that can classify the message asbeing unwanted content.

The above are the benefits of Greylisting for the receiver; they hint atthe challenges they impose on legitimate senders, and we'll go intothose now.

Greylisted messages are retained in the spool and queueing mechanisms ofthe sender until the messages are retried later on. A subsequent retrydoes not guarantee that the message will successfully leave the system;it may still be subject to greylisting on the receiving side. Thiscauses problems for senders; because the sender has no information onhow long it will be before the receiver will accept the message, theremay be several attempts to deliver. Each delivery attempt results in IOand CPU costs to bring the message in from the spool and network coststo transmit the message. This is wasteful because, in this case, it isunnecessary.

At the opposite end of this is that the sender may opt to wait longerthan is necessary to wait before attempting delivery, just based on theway that the majority of MTA software handles a retry schedule (it iscommon practice to exponentially back-off using a base period of about15-20 minutes, meaning that after the first attempt the sender will wait15-20 minutes before the next attempt; if that one is also transientlyfailed, then it will double the interval before the third attempt, anddouble it again for the fourth attempt and so on).

Applicant's Adaptive Delivery invention solves these greylistingproblems by recognizing a greylisting type of response and intelligentlyrevising the delivery schedule for messages on the same queue as thatmessage.

For instance, as illustrated in FIG. 8 (illustrating reactive processingin the face of greylisting), if a given message were being sent from asystem using the method of the present invention to some other MTA, andthat MTA responded with: 450 Greylisted, Applicant's solution wouldrecognize this response via the following rule definition (and allow thelocal administrator to configure similar rules):

{ code = “(?i)grey ?list”; trigger = “1”, action = {“greylisted”, “15minutes”}, phase = “each_rcpt”, },

In this rule, the “code” line defines a Perl Compatible RegularExpression (PCRE) that matches the following substrings in the protocolresponse, case insensitively: “greylist” or “grey list”. If a match isfound, the “trigger” line defines a triggering threshold, in this caseit specifies that the action will trigger immediately. The “action” linespecifies which system defined action (or actions) should be carried outwhen this rule is triggered. In this case, it triggers the “greylisted”rule with a parameter of “15 minutes”. The “phase” line scopes the ruleto a particular phase of the SMTP protocol dialog; in this case, it isreferring to the RCPT TO portion, which expresses each of a list ofrecipients.

The “greylisted” action used by the rule in this case has the effect ofrevising the delivery schedule for the queue of mail associated with themessage, adjusting two important aspects of the retry schedule. Asmentioned above, most MTAs use an exponential backoff to manage theretry schedule; Applicant's solution does this too, with the base periodbeing controlled by a parameter Applicant calls “retry_interval”.Applicant also has another parameter that Applicant calls“max_retry_interval” which sets an upper bound on the retry interval Forinstance, if retry_interval=15 mins, then the retry schedule would be15, 30, 60, 120, 240 and so on. By setting max_retry_interval=60, theretry schedule would be 15, 30, 60, 60, 60.

The greylisted action has the effect of intelligently adjusting both ofthese parameters based on the time period parameter passed in via therule: action={“greylisted”, “15 minutes”}.

Applicant's invention will look at the retry_interval parameter; if itis less than 15 minutes, Applicant's invention will raise it to 15minutes. This type of adjustment is justified because retrying too soonwill simply waste CPU and IO resources. Applicant's invention will lookat the max_retry_interval parameter; if it is less than four times theaction parameter (in this case, 4 time 15=60 minutes), Applicant'sinvention will raise it to 60 minutes. The rational is similar to theabove; having it too small is wasteful, but setting it too large maycause the system to wait too long before sending the message and maycause the sender to be greylisted again, causing an even longer delay.

Another facet of Applicant's invention is to dynamically react toresponses that indicate that the sender reputation is in jeopardy.Picture the following scenario; an email campaign is sent that has apoor choice of graphics or wording and causes a number of the recipientsat the same recipient domain to flag the message as spam. The operatorof the domain may automatically enact a temporary block targeted at thesender to prevent more of their users from reporting spam, asillustrated in FIG. 9. This type of block may result in subsequentdelivery attempts receiving the following transient failure response:

421 4.7.0 [TS01] Messages from 10.0.0.1 temporarily deferred due to usercomplaints—4.16.55.1

Most MTAs will treat this just like any other transient failure andrequeue the message per the usual retry schedule. In this case, therecipient domain publish their policy in this regard to be that thesender should not send any more messages for the next 4 hours. (in thepreferred embodiment, at present). If the sender is using the typicalretry schedule mentioned above, then they will be wasting resources bymaking those attempts, and may even be aggravating the situation withtheir reputation, as some receivers may decide that the repeatedattempts are still too much and may escalate the block to be morepermanent or wider reaching (perhaps blacklisting on a sharedblacklist).

Applicant's invention avoids these cases with the use of rules (that canbe modified or overridden by the local administrator) that can recognizethis type of behavior. An example of one of these rules is found inTable 1.

The “code” line is a PCRE that matches the type of response in theexample above. In this case, the “phase” is “connect”, meaning that therule is only assessed when connecting and not in subsequent phases ofthe SMTP protocol dialog (this reduces the amount of effort required tofully process the entire set of rules in use by the system). Thecritical part of this rule definition is that the “action” is set to“suspend” with a parameter of “4 hours”.

In Applicant's solution, the “suspend” action causes the queueassociated with the message to have its delivery schedule suspended forthe period specified; in this case, 4 hours. This means that the systemwill not waste any resources making attempts to deliver messages thatwill not make it out to the destination, and avoid potentially damagingthe sending reputation any further.

When a suspension is enacted, Applicant's system will send an alert tothe local administrator (or a list of users) to notify them of thatfact, and perhaps give a suggestion of what steps should be taken (inthis case none, but a later rule will illustrate this).

The suspensions that are currently in effect can be assessed by thelocal administrator and overridden if need-be (for instance, if theadministrator remediated directly with the recipient and cleared theblock). Another similar response might be the following: 421 4.7.1[TS03]—All messages from 10.0.0.1 will be permanently deferred.

In this case, as illustrated in FIG. 10, the recipient has decided thatthey never want to receive any mail from the sender, most likely due toa persistent or recurring level of complaints about the sender, and noamount of retries will allow the mail to be accepted by the systemunless some remediation takes place with the operator of the recipientdomain.

This has similar ramifications to the scenario above; the sending systemwill continue to waste resources making attempts that will neversucceed. Applicant's solution avoids the resource wastage by using therule shown in Table 1.

This is very similar to the preceding example, except that the “code”matches the SMTP response in this scenario, and that is demonstrates the“message” line, which is used to provide a suggestion to the localadministrator that s/he has some action to take.

Another possibility allowed by Applicant's solution is to take thatresponse to heart and to purge all mail queued to that recipient fromthat mail queue, and arrange for any subsequently received messagesdestined for that queue to be purged without making a delivery attempt.Applicant call this a “blackhole” because the mail is lost in theblackhole. Applicant might phrase the blackhole rule shown in Table 1.

The operation of the blackhole would be to modify the receptionprocessing mail flow so that any newly received mail destined for thesame queue will be marked as permanently failed due to a blackhole (andthus never make an attempt to deliver it), and also will apply the samelogic to all of the messages currently in that queue. The blackhole willbe temporary and last for a period of 4 hours.

This is much more efficient than trying to send the mail again later;presumably, one of the reasons that the sender was blocked was based onproperties of their messages that a large volume of recipients disliked,and there is a high likelihood that the mail that becomes backed up bysuch a mail block will be more copies of the same content; sending itonce the block is lifted is likely to cause the sender to be blockedagain. So, purging the queue not only saves resources until thesituation is resolved with the recipient, but also minimizes the risk ofsending the offending content to more users once it has been resolved.

Another problem scenario is that to do with the rate at which messagesare being sent, rather than there being problems with the content ofthose messages. There are a couple of different ways that receiverstrack the reception rate of messages, and these are influenced by theway that the SMTP protocol operates.

The first obvious metric is the total number of messages received from aparticular source IP address. The next metric is the number of messagesreceived on a given SMTP session (here, session refers to a discreteconnection to established from the sender to the receiver). And the nextmetric is the number of recipients that comprise a batch in SMTP.

If a sender tries to send “too many” messages in a given session, asillustrated in FIG. 11, the receiver may have a policy that sends back aresponse like the following: 421 Error: too many messages in onesession.

The prior art in MTA technology will treat this as a regular transientfailure and will continue to butt up against that policy. This can havelong term harmful effects on the reputation of the sender, as thereceiver may have policies in place that cause that sender to be placedon an internal block list if the behavior persists. There is also theincreased cost to the sender of having to retry the messages againlater.

Applicant's invention reduces the impact of this by the use of a rule(and additional similar rules can be defined by the local administrator)as shown in Table 1.

The “code” line matches the SMTP response cited above. The “phase” linescopes this particular rule to the phase of the SMTP dialog where a newbatch of mail is being initiated via the “MAIL FROM” command. The“action” line instructs the adaptive delivery module to reduce themaximum number of deliveries per session by 1, so that the next timethat messages are delivered to that recipient, the sending system willinitiate fewer batches before closing the session. If there is stillmail queued after closing the session, the sending system will initiatea new connection/session (this sentence is prior art).

As illustrated in FIG. 12, If a sender tries to send “too many” messagesover the course of some receiver policy specific time period, thereceiver may decide to issue an SMTP response that looks like thefollowing: 452 Too many recipients received this hour.

The prior art in MTA technology will treat this as a regular transientfailure and will continue to butt up against that policy with the sameimplications and effects as described above.

Applicant's invention reduces the impact of this by the use of a rule(and additional similar rules can be defined by the local administrator)as shown in Table 1.

The “code” line matches the SMTP response cited above. The “phase” linescopes this particular rule so that it is only evaluated duringconnection establishment. The “action” line specifies that the sendingsystem should adjust its message-sending throttle downwards. InApplicant's present implementation, each invocation of the “throttledown” action causes a 10% reduction in the throttle setting. Since theresponse contains no indication of the preferred reception rate, it maytake a few occurrences of this response to cause the throttle to fall toa level that is acceptable to the receiver.

Another traffic shaping metric that is used by receivers is the numberof connections established to the receiver from the sender, asillustrated in FIG. 13. The rationale is that a high number ofconnections may indicate abusive behavior. If a sender exceeds thislimit (and the limit is something that is entirely covered by thereceiver policies, and may even be dependent upon the connecting IPaddress), then they may encounter a response along the lines of thefollowing: 421 too many concurrent SMTP connections; please try againlater.

The prior art in MTA technology will treat this in the same way asregular transient failures as described above, with all the sameramifications.

Applicant's invention deals with this with the use of rules similar tothat shown in Table 1.

The important part of this rule is the “action” line, which reduces thenumber of allowed concurrent connections to the receiver by 1. As withthe other similar rules above, it may take a number of occurrences ofthis response to tune the effective value to be within tolerable limitsof the specific receiver.

Another scenario is that a receiver may decide, based on unusual sendingbehavior, establish a dynamic block and issue a permanent failureresponse to all messages originating from your address for a certainfixed time period. An example response might be as follows, althoughthis particular item has identifying information replaced with a genericexample URL: 554 RLY:B1 dynamic block http://example.com/rlyb1.html.

As shown in FIG. 14, the impact that this has on prior-art MTAs is thatthey will fail all messages that they attempt to send to thatdestination while the block is in effect. In reality, this particularclassification is transient (the actual URL in the real-life responsedetails that the block will expire after 24 hours), which means thesubsequently injected (with respect to the block being established)messages will be failed out-of-hand, even though they may be radicallydifferent from the content of the messages that triggered the block.

Applicant's invention, as illustrated in FIG. 15, allows the response tobe transcoded from a permanent to a transient failure (or vice-versa)using a rule like that shown in Table 1 (and as usual, additional rulesmay be defined by the local administrator).

In this case, the “action” specifies that two actions be carried out: 1)rewrite the response code from 554 to 454, converting it from apermanent to a transient response, causing the message that encounteredthe error to be retried later. 2) enact a suspension lasting 2 hours.

This has the effect of requeuing the messages in a reasonably efficientmanner; rather than retrying per the usual retry schedule, the messageswill remain in the queue for the next 2 hours; once the suspension islifted, the messages will be attempted again. If they encounter the sameresponse, they will be transiently failed and a suspension triggeredagain.

Some receivers maintain data on the historical sending rate ofparticular sending IP addresses. Their policies place limits on theallowed reception rate of the IP based on the establishment of a goodreputation over time. If they have never seen a particular IP addressbefore, they will use fairly restrictive settings on the allowedreception rate, and issue transient failures if these rates areexceeded. As the receiver becomes more familiar with the sender, basedon the overall message volume and length of time that the system hasbeen sending, they will increase the permitted reception rate. Thisconcept is known as “IP Warmup” in the industry.

The prior-art MTAs have no mechanism to adapt to this type of time basedrate control, requiring explicit configuration changes to adapt.Applicant's invention improves on this in two ways.

The first of these is being able to configure a parametric rate for thereceivers that are known to have these policies. An example parametricthrottle rate is shown below:

outbound_throttle_messages=function(last,curr,age,mc)

-   -   100/hr for 4 days,    -   raise to 1000/hr for next 5 days

age=age/86400;—convert to age in days

if age <=4 then return 100; end if age <=10 then return 1000;

end return 0; end,

This is expressed as a function in the “Lua” language. The parameters tothe function are:

Curr—the current value for the outbound message throttle rate, which mayinclude a speculative adjustment

Last—the value for outbound message throttle rate that was used up untilthis point

Age—the locally recorded age of the IP address

Mc—the locally recorded message volume sent from this IP address to thereceiver in question

As the comment in the function indicates, this particular setting causesthe throttle rate to be set to 100 messages per hour for the first 4days that the IP address is used, upscaling to 1000 messages per hourfor the next 5 days, and then removes the throttle after that timeperiod.

The age of the IP address is assumed to be 0 when the system is firstprovisioned, but this can be explicitly set by the local administrator.Similarly for the “mc” parameter (the message volume), although inApplicant's current embodiment, Applicant doesn't track the messagevolume and have no rules that use it.

The other facet of Applicant's invention that improves on the prior artin the face of “IP Warmup” receiving policies is the ability todynamically react to responses that indicate that Applicant should doso, as shown in FIG. 16. For instance, if a given IP address with anestablished reputation reduces its sending rate to zero for an extendedperiod of time, a receiver may decide to reset it so that it has aninfant status.

If the sender were then to ramp up their sending to the levels that werepossible with the prior reputation, they may run into a response likethis: 412 RP-001 the mail server IP has exceeded the rate limit.

This response can also arrive if the complaint volume for the sendingraises too high and triggers an automated temporary block.

In both cases, the recommended practice is to re-warm the sending IPaddress, as illustrated in FIG. 17. The prior-art MTAs have nocapability to do this, effectively suspending their outbound mail flowto that particular destination, but through the use of rules like thatshown in Table 1 (which can also be set by the local administrator),Applicant's invention allows mail to flow once again, albeit at a lower,more acceptable rate.

The “warmup” action causes the recorded age of the IP address inquestion to be reset, starting causing the parametric throttle rate toselect a lower value.

Periodic Parameter Adjustment:

A lot of the techniques above are used to adjust the traffic shapingparameters downwards in response to events that indicate that the ratesshould be reduced.

While this is an effective means to automatically reduce rates, therealso needs to be a mechanism that works in the opposite direction toincrease rates if it seems like it would help.

The prior art in this area is not automated; the local administratormust manually adjust the shaping parameters to suit the changing needsof their system.

The adaptive delivery invention employs a simple heuristic in itscurrent embodiment; when evaluating the value of a traffic shapingparameter (such as the number of concurrent connections, or the rate atwhich messages should be sent), if the system has not made a negativeadjustment within a configurable time period (default 1 hour), then thesystem will speculatively increase the value of the parameter by 1.

This allows the system to gradually open up the sending rate, withoutmanual intervention, after it has been calmed by one of the techniquesdescribed in the preceding pages.

Periodic Aggregate Disposition Checks:

The majority of the functionality described in the preceding pages talksabout reactions to specific responses encountered by the system whenattempting to deliver to a recipient. The protocol indicates that theseresponses are primarily geared towards information the sender of thestatus of the reception of a given message payload, although it ispossible that the recipient will send back more of a blanket responseduring the connection phase if they have opted to establish a mailblock.

Having a system based purely on individual message disposition resultsis not sufficient for managing a good sending reputation (and thushaving an optimal sending rate); if the messages are being rejected at ahigher than usual (or otherwise acceptable) rate by the receiver, it isindicative of a problem that can require intervention to preserve thesender reputation. For instance, perhaps a typo was made in some messagecontent causing it to be offensive, or perhaps an overly aggressivemarketing campaign looks more like spam mail than it should, or in thecase of Email Service Providers (organizations that provide outsourcedemail sending capabilities for others), a customer violates terms ofservice and deliberately sends spam mail.

In these cases, the complaint or rejection rate will be unusually highand indicates that a mail block is likely to be enacted if the behaviorcontinues. The prior-art message relaying technology does not have anyautomated mechanisms to manage this. Most sending institutions have setup business level monitors that alert an operator to take manual action.Applicant's invention improves on this situation by automatically takingactions and sending alerts.

As shown in FIG. 18, Applicant's solution records the volumes ofmessages that were attempted, succeeded and failed for each source IP toeach recipient domain.

Applicant also recognizes that the reason why a receiver rejects a givenmessage can be fairly nuanced. Applicant's solution, like some others(so this paragraph is effectively prior art and not a claim) classifiesSMTP responses and out-of-band bounce reports into one of a number ofreasons.

Broadly speaking, “bounce classification” is not suitable to solve theproblems solved by the system and method of the present invention,instead, applicants' system records the volume of each of the bounceclassifications over time and may then act in response to this as partof periodic aggregate disposition checks.

In addition, Applicant's software also records the volumes of Feed-BackLoop (FBL) complaints that are sent back to the system from the majorreceivers, as illustrated in FIG. 19. The FBL is a standard mechanismfor relaying information about user complaints from the major ISPs.These are implemented via a “report spam” or similar button in theend-user email software. When a user complains, the ISP records this,and if the sender has arranged to be a part of the FBL with thatreceiver, a special FBL report email is sent back to the sender. Theconcept with the FBL is that the sender will take steps to remedy thecomplaint in short order, with the typical resolution being that therecipient should be unsubscribed or otherwise taking steps to avoidsending content to that recipient again.

FBL complaints are sensitive, with the major ISPs likely to enact ablock against a sender if the complaint rate rises to something in therange of 0.5% to 1% of the volume of messages from that sender.

FBL complaints can be categorized into one of the following: abuse,fraud, invalid dkim signature, virus and other. So, in accordance withthe present invention, a periodic aggregate disposition is evaluated.

For a simple example, say an administrator wants to suspend deliveriesif 10% or more of message traffic is being rejected by a givenrecipient. However, the threshold needs to be statistically significant;if a sender sends one message and it is rejected immediately, therejection rate is effectively 100% at that point. So, in accordance withthe present invention, a parameter is provided that allows theadministrator to specify the minimum amount of messages that need tohave been attempted before this processing can take effect. An exampledefault for this threshold parameter is 100 messages.

The system of the present invention processes the periodic aggregatedisposition checks every hour (configurable) and provides a number ofdifferent rules (that can be configured by the local administrator) tocontrol the behavior.

For example, as shown in FIG. 20, the illustrated configuration causes asuspension to be enacted when the total rejection rate, based on theprotocol level responses, reaches 10%, but only if at least 100 messageshave been attempted:

Adaptive_Rejection_Rate_Suspension_Percentage=10

Adaptive_Attempt_Threshold=100

For more granularity, rules such as the following can be specified:

Codes = ( “bc:10” “bc:23” “bc:22” ) # correspond to bounce codes tableabove     Low_Threshold = 3 Low_Action =( “throttle” “down” )    High_Threshold = 10     High_Action = ( “suspend” “4 hours” )

This rule states that if the total volume of rejections classified as aninvalid recipient, mailbox full or message too large reaches 10%, thenthe message flow to that recipient domain will be suspended. Otherwise,if the rate reaches 3% then the system will reduce the sending rate by10% (per the description of throttle down earlier in this document).

The actions that can be specified here are the same as those describedin the earlier part of this document.

The list of codes can be chosen by local administrator and the rules canthemselves be specified on a per recipient domain per sending IP basis.

An example of using the FBL data:

Codes = ( “fbl:abuse” )   Low_Threshold = 0.3 Low_Action = ( “throttledown” )   High_Threshold = 0.5     High_Action = (“suspend” “4 hours”)

This rule has the effect of reducing the sending rate once the FBL abusecomplaint rate reaches or exceeds 0.3%, and suspending the sending if itreaches 0.5%.

Since these rules are assessed every hour (configurable), the LowThreshold may trigger multiple times, having a stronger calming effectover time.

Applicant's invention records the bounce classification and overallvolume statistics windowed to a 1 hour interval (configurable), whichhas the effect of automatically causing the statistics to fall below thetriggering threshold over time. Applicant's invention records the FBLdata over a longer time period of 24 hours (configurable) since the lowtrigger threshold and established practices of the receivers requirethis in order for the solution to be effective.

Having described preferred embodiments of a new and improved method andsystem 200, it is believed that other modifications, variations andchanges will be suggested to those skilled in the art in view of theteachings set forth herein. It is therefore to be understood that allsuch variations, modifications and changes are believed to fall withinthe scope of the present invention.

TABLE 1 Message Rule Name Code Trigger Action Notification Phase (a)Example of Rules In a Typical Rule-set Transcode 421 4\\.7\\.1 1transcode”, “Remediation connect \\[TSO3\\] All “554”, with    messages“blackhole”, “4 required”, from hours”} (?<IPADDRES S>\\d+\\.\\d+\\.\\d+\\.\\d+) will be permanently deferred” Suspension 421 4\\.7\\.0 5/1{“suspend”, “4 connect \\[TS02\\] hours”}, Messages from (?<IPADDRESS>\\d+\\.\\d+\\.\\ d+\\.\\d+) temporarily deferred due to usercomplaints- 4\\.16\\.56” Warmup 421 PR\\(dt1\\) 1 {“warmup”, connect*The mail “1”}, server IP connecting to Windows Live Hotmail server hasexceeded the rate limit allowed on this connection. (b) Example of RulesIn a Typical Rule-set Greylist “(?i)grey ?list”; 1 {“greylisted”,“rcptto “15 minutes”} Reputation 421 4\\.7\\.0 1 {“suspend”, “4 connectIn Jeopardy \\[TS01\\] hours”}, Messages from (?<IPADDRESS>\\d+\\.\\d+\\.\\ d+\\.\\d+) temporarily deferred due to usercomplaints- 4\\.16\\.55\\.1”, Remediation 421 4\\.7\\.1 1 {“suspend”, “4“Remediation connect Required \\[TS03\\] All hours”}, with Operatormessages Name from required”, (?<IPADDRES S>\\d+\\.\\d+\\.\\ d+\\.\\d+)will be permanently deferred” Blackhole 421 4\\.7\\.1 1 {“blackhole”,Remediation connect \\[TS03\\] All “4 hours”} with Operator messagesName required” from (?<IPADDRES S>\\d+\\.\\d+\\.\\ d+\\.\\d+) will bepermanently deferred” Too Many 421 Error: too 1 {“throttle”, mailfromMessages many “down”}, Per Session messages in one session” (c) Exampleof Rules In a Typical Rule-set Too Many 452 .*Too 1 connect Recipientsmany Per Hour recipients received this hour” Connection 421 Too many 1{“reduce_connections”, connect Problem concurrent SMTP connections;please try again later” Dynamic 554 RLY:B1” 1 {“transcode”, Dynamicblock connect Block “454”, in place” “suspend”, “2 hours”}, IP Warmup“421 RP- 1 {“warmup”, connect 00[123]”, “1”},

We claim:
 1. An improved method for delivering a plurality of digitalmessages to recipients at a plurality of recipient domains, said methodof the type that is used by a systems administrator and includes thesteps of: (i) utilizing a plurality of operating techniques for sendingsaid digital messages to each of said recipient domains, (ii) receivingand storing message delivery disposition information from said recipientdomains for each of said digital message received by one of saidrecipient domains, (iii) establishing a set of rules for yieldingevaluations over a specified monitoring period for said message deliverydisposition information, wherein said rules pertaining to parametersthat include the rate of connection attempts made, time-outnotifications received, spam block notifications received or deliveryfailure notifications received per said specified monitoring period,(iv) establishing reactive actions, in response to said evaluations overa specified period of time of said message delivery dispositioninformation, to be taken to modify said operating techniques so as tomaintain a targeted success rate for the delivery of said digitalmessages, wherein said actions include aborting, postponing, deferringand discontinuing said delivery of said digital messages, and (v)implementing, at the conclusion of one of said specified periods oftime, said responsive actions in response to said evaluations over aspecified period of time of said message delivery dispositioninformation, the improvements to said method, which allow for anincrease in said targeted success rate for the delivery of said digitalmessages, comprising the steps of: making real-time, at the instant saidmessage delivery disposition information is received, multi-partassessments of said message delivery disposition information receivedfrom said recipient domains so as to determine in real-time whether achange in the operating techniques of said method is needed in order toensure the continuation of a high success rate for the delivery of saiddigital messages, establishing a plurality of real-time, updatingactions to change in real-time said operating techniques of said method,and wherein each of said real-time, updating actions corresponding toone of said parts of said real-time, multi-part assessments of saidmessage delivery disposition information, and automatically, byutilizing a part of said real-time, multi-part assessments, implementingin real-time one of said plurality of real-time, updating actions so asto allow for an increase in said targeted success rate for the deliveryof said digital messages.
 2. The improved method for delivering aplurality of digital messages as recited in claim 1, wherein: saidreal-time, multi-part assessments utilize a Rule-set.
 3. The improvedmethod for delivering a plurality of digital messages as recited inclaim 2, wherein: said Rule-set includes a regular expression patternmatching tool.
 4. The improved method for delivering a plurality ofdigital messages as recited in claim 3, wherein: said Rule-set furtherinclude a phase metric and a trigger.
 5. The improved method fordelivering a plurality of digital messages as recited in claim 1,wherein: said updating action chosen from the group herein defined as atranscode, purge, suspend, blackhole, throttle, warmup, greylist, reduceconnections, and reduce deliveries action.
 6. The improved method fordelivering a plurality of digital messages as recited in claim 2,wherein: said updating action chosen from the group herein defined as atranscode, purge, suspend, blackhole, throttle, warmup, greylist, reduceconnections, and reduce deliveries action.
 7. The improved method fordelivering a plurality of digital messages as recited in claim 3,wherein: said updating action chosen from the group herein defined as atranscode, purge, suspend, blackhole, throttle, warmup, greylist, reduceconnections, and reduce deliveries action.
 8. The improved method fordelivering a plurality of digital messages as recited in claim 4,wherein: said updating action chosen from the group herein defined as atranscode, purge, suspend, blackhole, throttle, warmup, greylist, reduceconnections, and reduce deliveries action.
 9. The improved method fordelivering a plurality of digital messages as recited in claim 1,further comprising the step of: providing a message notification to saidsystem administrator that alerts said administrator that an updatingaction is being taken.
 10. The improved method for delivering aplurality of digital messages as recited in claim 8, further comprisingthe steps of: providing a message notification to said systemadministrator that alerts said administrator that an updating action isbeing taken.
 11. A method that is used by a systems administrator fordelivering a plurality of digital messages to recipients at a pluralityof recipient domains so that a targeted success rate for the delivery ofsaid digital messages is maintained, said method comprising the stepsof: utilizing a plurality of operating techniques for sending saiddigital messages to each of said recipient domains, receiving messagedelivery disposition information from said recipient domains for each ofsaid digital message received by one of said recipient domains, makingreal-time, at the instant said message delivery disposition informationis received, multi-part assessments of said message delivery dispositioninformation so as to determine in real-time whether a change in theoperating techniques of said method is needed in order to ensure thecontinuation of the achievement of said targeted success rate for thedelivery of said digital messages, establishing a plurality ofreal-time, updating actions to change in real-time said operatingtechniques of said method, and wherein each of said real-time, updatingactions corresponding to one of said parts of said real-time, multi-partassessments of said message delivery disposition information, andautomatically, by utilizing a part of said real-time, multi-partassessments, implementing in real-time one of said plurality ofreal-time, updating actions.
 12. The method for delivering a pluralityof digital messages as recited in claim 11, wherein: said real-time,multi-part assessments utilize a Rule-set.
 13. The method for deliveringa plurality of digital messages as recited in claim 12, wherein: saidRule-set includes a regular expression pattern matching tool, a phasemetric and a trigger.
 14. The method for delivering a plurality ofdigital messages as recited in claim 11, wherein: said updating actionchosen from the group herein defined as a transcode, purge, suspend,blackhole, throttle, warmup, greylist, reduce connections, and reducedeliveries action.
 15. The method for delivering a plurality of digitalmessages as recited in claim 13, wherein: said updating action chosenfrom the group herein defined as a transcode, purge, suspend, blackhole,throttle, warmup, greylist, reduce connections, and reduce deliveriesaction.
 16. A computer program product for use in conjunction with acomputer system, the computer program product comprising a computerreadable storage medium and instructions thereon for delivering aplurality of digital messages to recipients at a plurality of recipientdomains so that a targeted success rate for the delivery of said digitalmessages is maintained, said instructions comprising the steps of:utilizing a plurality of operating techniques for sending said digitalmessages to each of said recipient domains, receiving message deliverydisposition information from said recipient domains for each of saiddigital message received by one of said recipient domains, makingreal-time, at the instant said message delivery disposition informationis received, multi-part assessments of said message delivery dispositioninformation so as to determine in real-time whether a change in theoperating techniques of said method is needed in order to ensure thecontinuation of the achievement of said targeted success rate for thedelivery of said digital messages, establishing a plurality ofreal-time, updating actions to change in real-time said operatingtechniques of said method, and wherein each of said real-time, updatingactions corresponding to one of said parts of said real-time, multi-partassessments of said message delivery disposition information, andautomatically, by utilizing a part of said real-time, multi-partassessments, implementing in real-time one of said plurality ofreal-time, updating actions.
 17. The computer program product for use inconjunction with a computer system as recited in claim 16, wherein: saidreal-time, multi-part assessments utilize a Rule-set.
 18. The computerprogram product for use in conjunction with a computer system as recitedin claim 17, wherein: said Rule-set includes a regular expressionpattern matching tool, a phase metric and a trigger.
 19. The computerprogram product for use in conjunction with a computer system as recitedin claim 16, wherein: said updating action chosen from the group hereindefined as a transcode, purge, suspend, blackhole, throttle, warmup,greylist, reduce connections, and reduce deliveries action.
 20. Thecomputer program product for use in conjunction with a computer systemas recited in claim 18, wherein: said updating action chosen from thegroup herein defined as a transcode, purge, suspend, blackhole,throttle, warmup, greylist, reduce connections, and reduce deliveriesaction.